# Claude Code 验证循环实战教程 > 让 AI 写完代码后自己验收，验证循环的原理和实战 大家好，我是程序员鱼皮。 最近 Claude 官方发了一篇博客，专门讲怎么让 Claude Code 自己检查自己写的代码，官方管这个叫 Verification Loop 验证循环。 简单来说，就是 AI 写完代码以后不急着交差，而是先自己跑一遍检查。有问题就继续改，改完再检查，形成一个循环，直到全部检查通过以后才交付给你。 > 原文指路：[https://claude.com/blog/building-verification-loops-in-claude-code-with-skills](https://claude.com/blog/building-verification-loops-in-claude-code-with-skills) ![](https://pic.yupi.icu/chengfang/1786413234706-10e92ec5-2867-4fc4-bdc7-207583033002.png?imageSlim) 不过话说回来，现在 AI 写代码是真的快，可是每次它自信地跟我说「搞定了」，我还是得自己打开页面、一个功能一个功能试、切换到手机端再测、最后打开浏览器控制台看有没有报错。 代码是它写的，怎么最后验收还是我的活？ 所以我倒要试试，Claude 官方的这套验证循环，到底能不能真让我少干点活。 ![](https://pic.yupi.icu/chengfang/2.jpeg?imageSlim) ## 什么是验证循环？ Claude Code 在开发过程中本来就会做一些基础检查，比如： - 类型检查，确认变量类型有没有写错 - 代码规范检查，有没有少写分号之类的低级问题 - 自动化测试，跑一遍预设的测试用例 - 还有运行时报错，代码能不能稳定运行 这些检查都能给出明确的对错结果，AI 可以根据结果继续修改代码。 但是，这些基础检查覆盖不了所有最终效果。像手机端有没有布局错乱、按钮到底能不能点、页面有没有严重遮挡，这些问题光靠跑代码检查工具是发现不了的，最后还是得自己打开页面亲眼确认。 所以我平时用 AI 开发的流程一般是这样的：先让 AI 把代码写完、跑一些基础检查，然后我再实际操作一遍。发现问题以后告诉 AI 哪里不对，让它继续改。 但是换成 Verification Loop 以后，后面人工验收的部分也可以交给 AI 来干了。让 AI 自己验证、自己修改，全部通过以后再交付给我。 ![](https://pic.yupi.icu/chengfang/01-AI.png?imageSlim) 当然，光跟 AI 说一句「你自己检查一下」肯定不够。它得知道具体该检查什么，也得拿到一个能够判断「到底过没过」的明确结果。 在这方面，Claude 官方提到了好几种内置的验证方式： + `/verify` 技能，让 AI 自己构建项目、运行起来、然后观察改动有没有问题 + Toolchain，也就是利用项目里已有的工具链（比如代码检查工具），让 AI 直接读取工具返回的错误和警告来判断 + Code Review，一个自动审查代码改动的多 Agent 服务，可以在 PR（代码合并请求）上自动跑一遍审查 + GitHub Actions，在代码提交时自动触发检查流程 + Spec validation，按照项目里的需求规格文档来验证改动 + Rubrics，按照评分标准来打分，不及格就打回去重做 这些名字不用记住，核心思路都是一样的：**给 AI 一个明确的检查结果，让它能判断这次到底是通过还是失败。** 程序能不能正常运行、测试有没有通过、代码提交有没有问题，都属于这种能够明确判断对错的结果。 甚至项目自己定的特殊规则，也可以变成验收条件。 那么你可能要问了：什么是项目自己定的特殊规则？ 举个例子，假如数据库迁移要删掉一列数据，但是没有事先把数据备份保留下来，那这次修改就直接判定不通过。 这种规则是你的项目自己定的，通用的代码检查工具根本不知道这回事，但同样可以写进验证流程，让 AI 每次都按照这个标准来验。 ![](https://pic.yupi.icu/chengfang/02-AI.png?imageSlim) ## 用 Skill 把验证循环固定下来 如果你每次要重复的不只是一两条规则，而是一整套检查动作，那就可以把它们整理成 Skill 技能。 Skill 的本质就是一个 Markdown 文件，里面用自然语言写清楚检查步骤，放到项目的 `.claude/skills/` 目录下。以后再遇到类似的任务，AI 直接按照这套流程执行，不需要你每次重新教一遍。 官方推荐的上手路径是这样的： 1. 先从一项最常重复的人工检查开始，比如试试 Claude Code 里内置的 `/verify` 技能，输入这个命令以后，AI 就会自己构建项目、运行起来、然后检查改动有没有问题。 2. 觉得不够用的话再自己写。你可以把检查流程用自然语言描述出来，交给 `skill-creator` 插件帮你生成，它会理解你的工作流程然后自动生成对应的 Skill 文件。当然也可以自己手写一个 Markdown 文件，放到技能目录下就行。 3. 拿新任务跑一遍，看看哪里不好用就继续迭代。等单个检查稳定了，再尝试把多个检查串起来。 ![](https://pic.yupi.icu/chengfang/03-AI.png?imageSlim) 一个简单的 Skill 文件长这样： ```yaml # .claude/skills/verify-log-hygiene/SKILL.md --- name: verify-log-hygiene description: 检查错误日志是否包含请求 ID，并且不能泄露请求体内容。 --- 读取当前代码改动中的错误处理路径。 对于每一个错误路径上的日志调用，确认它包含了请求 ID， 并且没有把请求体、请求头、或用户提交的任何数据写进日志。 逐条报告违规项（标注文件名:行号），然后修复它。 ``` 上面这个 Skill 的作用是检查日志规范。你可以看到，它就是一段 YAML 格式的头信息（名字和简介）加上几段自然语言写的检查指令，告诉 AI 该看什么、怎么判断、发现问题怎么处理。没有想象中那么复杂，本质上就是把你平时脑子里的检查流程用文字写下来。 像我平时检查前端页面，就会反复检查页面加载、核心交互、移动端适配、浏览器控制台这些东西，每次都是同样的流程。所以这次我干脆把它们写成了一个 `verify-frontend` Skill，让 AI 自己对照着验收。 ![](https://pic.yupi.icu/chengfang/6.png?imageSlim) 不过要注意，**Verification Loop 是核心思路，Skill 只是实现它的一种方式**。你也可以用 Hooks 钩子（在特定时机自动触发的脚本）来实现类似的效果，甚至可以用 `/goal` 命令定义一个目标条件，让 AI 自己循环直到条件满足为止。 ## 实战验证 - 循环到底有没有用？ 哔哔了一大堆，这玩意到底有没有用呢？ 我决定设计一个对比实验来试试看。 同一个项目、同样的需求，第一轮正常让 AI 开发然后我人工验收，第二轮让 AI 开发完以后自己执行 Verification Loop 来验收。看看这套验证循环在实际开发中，到底能不能帮我省事。 本来我想直接在 Claude Code 里用 Claude 自家的模型来跑这个实验，但是我的 Claude 账号早就喜提封号了。。。 没办法，这次只能让 Claude Code 接 DeepSeek 模型给大家实测。具体怎么接入，可以阅读本教程编程工具板块 Claude Code 目录中的《Claude Code 和 Codex 对接国内模型教程》，这里就不展开讲了。 至于拿什么项目来测试，我选了最近挺火的竹知了~ 我直接给了 AI 几张参考图，让它搓一只 3D 赛博风格的竹知了出来。 初始版本的页面只有竹知了主体、缓慢自转和一个标题。 ![竹知了初始版本](https://pic.yupi.icu/chengfang/%E7%AB%B9%E7%9F%A5%E4%BA%86%E5%88%9D%E5%A7%8B%E7%89%88%E6%9C%AC.png?imageSlim) 然后我给 AI 下了 5 条需求： ```plain 1. 鼠标拖动控制竹知了的旋转和朝向 2. 普通 / 狂暴模式切换 3. 狂暴粒子光效 4. 375px 移动端适配 5. 整体视觉完善 ``` 为了尽量公平，两轮实验都从同一个初始版本开始，用的是相同的 DeepSeek 模型和同一套工具环境，而且每轮都重新开一个全新的 Claude Code 会话。 同时为了保证公平，我在第一轮开始之前就把第二轮要用的 6 类验收检查全部定好了，避免我看完第一轮结果以后再临时往规则里塞东西。 ![左侧为正常开发，右侧为 verify-frontend Skill](https://pic.yupi.icu/chengfang/1786418711345-bfcfaef7-69ea-490a-8991-117f9b730138.png?imageSlim) ### 第一轮、正常开发 这一轮我按平时开发的方式来，不告诉 AI 要额外测试，也不让它跑 `verify-frontend` Skill。 5 分 33 秒后，Claude Code 宣布完成。5 项需求都有对应实现，而且 AI 自己还主动检查了一遍项目能不能正常构建。 ![](https://pic.yupi.icu/chengfang/11.png?imageSlim) 来看看 AI 实现的效果。 我脑子里的「拖动竹知了」，其实是拿着棍子一甩，绳子受重力和惯性影响，下面的竹知了跟着晃，再配个「哇哇哇」的音效，美滋滋～ ![第一轮普通状态下竹知了](https://pic.yupi.icu/chengfang/%E7%AC%AC%E4%B8%80%E8%BD%AE%E6%99%AE%E9%80%9A%E7%8A%B6%E6%80%81%E4%B8%8B%E7%AB%B9%E7%9F%A5%E4%BA%86.png?imageSlim) 但是 AI 完全理解错了，它做出来的是鼠标按住模型以后，直接控制整个竹知了旋转。 我刚想吐槽，回头看了一眼自己写的需求。 ![](https://pic.yupi.icu/chengfang/12.png?imageSlim) 行吧，这真不能怪 AI。 我只写了「鼠标拖动控制竹知了的旋转和朝向」，根本没写绳子、重力、惯性这些东西。 ![](https://pic.yupi.icu/chengfang/13.png?imageSlim) AI 宣布完成以后，我还是老老实实自己验了一遍，功能基本都能用，不过狂暴模式的效果跟我想象中还是有点差距。虽然旋转确实变快了，但粒子和光效变化并不明显，只看图片的话，跟前面那个没啥区别。 ![第一轮狂暴模式下的竹知了](https://pic.yupi.icu/chengfang/14.png?imageSlim) 另外我还发现，浏览器控制台里躺着两条黄色警告。简单来说就是 3D 渲染库 Three.js 提示有两处旧的用法已经不推荐了，不过目前还能正常运行，所以不影响这次验收。 ![](https://pic.yupi.icu/chengfang/15.png?imageSlim) 总结一下这轮测试。AI 花了 5 分 33 秒写完代码，我又花了大概 2 分钟手动验了一遍。点交互、切换模式、测 375px、最后还得打开浏览器控制台看报错。 ### 第二轮、验收也交给 AI 第二轮我把代码回退到了竹知了最初的样子，也就是只有主体模型和缓慢自转的那个版本，确保两轮测试的起点完全一样。 前面那 5 条功能需求一字不改，只额外增加了一句话： ```plain 开发完成后必须执行 verify-frontend Skill，全部通过后才能宣布完成。 ``` 这次 AI 不光要写代码，还得把我平时会做的那些验收工作自己跑完。 还记得前面提到，我在实验开始前就定好的那 6 类检查吗？ + 项目能不能正常构建 + 页面能不能正常打开 + 核心交互有没有生效 + 375px 手机端有没有问题 + 浏览器控制台有没有报错 + 页面有没有明显错位、遮挡或者裁切 ![](https://pic.yupi.icu/chengfang/16.png?imageSlim) 为了让 AI 真正能操作页面，这次我给它配了两个工具。 1. Playwright 是一个浏览器自动化测试框架，相当于 AI 的「手」，能帮它打开网页、拖动模型、点击按钮这些真实操作。 2. Vision 视觉能力相当于 AI 的「眼睛」，让它能够截图并看懂页面长什么样，检查有没有明显的错位、遮挡或者裁切。可以用 GitHub 上开源的 [多模态视觉识别 Skill](https://github.com/asuojun/claude-vision-skill) ![](https://pic.yupi.icu/1/image-20260803155552049.png) AI 写完代码之后，会自动执行验收流程。 中间还出了个小插曲，Playwright 一开始因为依赖没装好所以没跑起来。不过这点小问题根本不需要人工处理，AI 自己排查出了原因、修好了依赖、然后继续往下验收。 ![](https://pic.yupi.icu/chengfang/17.png?imageSlim) 最终，按照实验前定好的规则，6 类检查全部通过了。 ![](https://pic.yupi.icu/chengfang/18.png?imageSlim) 这一轮任务总耗时 9 分 48 秒。而且从效果上来看，第二轮狂暴模式的粒子效果，比第一轮确实炫酷多了。 ![第二轮狂暴模式下的竹知了](https://pic.yupi.icu/chengfang/%E7%AC%AC%E4%BA%8C%E8%BD%AE%E3%80%8C%E7%8B%82%E6%9A%B4%E3%80%8D%E6%A8%A1%E5%BC%8F%E4%B8%8B%E7%9A%84%E7%AB%B9%E7%9F%A5%E4%BA%86.png?imageSlim) AI 在最终的验收报告里还记录了一条构建警告，提示打包后的文件体积超过 500 KB，还是挺细心的~ ![](https://pic.yupi.icu/chengfang/20.png?imageSlim) 不过和第一轮验收一样，打开浏览器控制台，我发现那两条警告信息还在。 ![](https://pic.yupi.icu/chengfang/19.png?imageSlim) 这也提醒了我，如果真要把验收交给 AI，光告诉它该验什么还不够。AI 具体用什么方式去检查（比如是看截图还是读控制台日志）、检查到异常以后怎么分类记录、最后怎么在报告里完整汇报出来，这些同样得在 Skill 里写清楚。中间任何一环有疏漏，都可能出现有问题却没有报告的盲区。 ## 两轮实验的对比结果 按照实验前定好的规则，两轮都通过了验收，也都没有发现影响功能的业务 Bug。 真正发生变化的，是验收这件事由谁来做。 第一轮 AI 写完以后，我自己点、自己看、自己测。 第二轮在 AI 宣布完成之前，我完全没有插手验收过程，它自己把整套流程跑完了。 代价就是，第二轮总耗时多了 4 分多钟。但这段时间不需要我守在旁边一个个手动点击屏幕，我可以去喝杯水、摸摸鱼、做一组提肛，回来直接看结果。这才是我觉得 Verification Loop 真正有价值的地方。 当然，「通过验收」和「效果完全符合预期」还是两回事。就像第一轮的狂暴模式，功能确实做出来了，但到底够不够狂暴、视觉效果满不满意，还是得人工来判断。 所以我觉得，真正适合先交给 AI 验收的，是那些能够明确判断对错、而且每次都要重复做的事情。比如项目能不能构建、核心交互有没有生效、手机端有没有适配问题、浏览器控制台有没有报错。 至于动画是不是太快、页面够不够好看、竹知了到底有没有小时候甩起来那个味儿，这些涉及主观审美和产品感觉的事情，最后还是得人来拍板。 在 AI 时代，审美和判断力才是人类最稀缺的能力。 ## 验证循环还能怎么玩？ 我这次只是在 AI 开发完成以后，单独跑了一遍验收。但 Verification Loop 并不只能放在最后一步。 等这套验收方式拿真实任务跑过几次、确定比较可靠以后，还可以把它嵌进日常开发流程，甚至跟其他检查串起来形成一条流水线。 Claude 官方把这些用法总结成了 4 种运行方式： ![](https://pic.yupi.icu/chengfang/04-AI.png?imageSlim) 1）Standalone 独立执行 需要的时候手动触发一次，比如提交代码前临时跑个安全扫描。 2）Embedded 嵌入到其他 Skill 里 把验证步骤直接写进生产 Skill 的末尾。比如你有一个自动创建 React 组件的 Skill，就可以在最后加一行「创建完成后跑一遍 eslint 检查」，这样每次用这个 Skill 的时候都会自动验证。 3）Chained 链式串联 多个 Skill 首尾相连，一个跑完自动触发下一个。 Anthropic 自己的 Claude Code 团队日常就是这么用的。先用 `/code-review` 命令找 Bug，再用 `/simplify` 命令精简代码，然后用 `/verify` 命令确认功能正常，如果改动涉及 UI 的话，最后还会用一个自定义的 `/design` Skill 比对设计规范。 这四步跑完，就是一整套全自动的代码质量保障流程，开发者只有在某一步出了问题、需要人工介入时才会收到通知。 ![](https://pic.yupi.icu/chengfang/05-AI.png?imageSlim) 4）On every PR 每次提交代码时自动执行 等链式流程在你自己的开发中跑稳以后，就可以把它挂到 GitHub Actions 上。这是 GitHub 提供的自动化流水线服务。 这样一来，团队里任何人提交代码合并请求，都会自动触发同一套验证检查，不需要靠每个人自觉去手动执行，代码质量有了统一的底线保障。 顺带一提，Claude Code 的创造者 Boris Cherny 在今年 6 月说过一句话：我已经不再手动给 AI 写提示词了，我现在的工作是设计循环，让循环去指挥 AI 该做什么。 ![](https://pic.yupi.icu/1/loop%20engineering.png) 这个理念在开发者社区里被叫做 Loop Engineering 循环工程，核心思想就是人类从「逐条指挥 AI」转变为「设计一套系统让 AI 自己运转」，而 Verification Loop 就是其中最关键的一环。 ![](https://pic.yupi.icu/1/01_Loop_Engineering%E6%A0%B8%E5%BF%83%E6%A6%82%E5%BF%B5%EF%BC%9A%E4%BD%A0%E8%AE%BE%E8%AE%A1%E7%B3%BB%E7%BB%9F%E8%AE%A9%E5%AE%83%E4%BB%A3%E6%9B%BF%E4%BD%A0%E7%BB%99AI%E4%B8%8B%E6%8C%87%E4%BB%A4_compressed_v1.png) 关于 Loop Engineering 的更多内容，可以阅读本教程经验技巧板块中的《Loop Engineering 保姆级教程》。 ## 写在最后 看到这里，你应该感受到了 Verification Loop 的作用。 如果你要用 AI 做完整的大项目，我建议你除了给 AI 需求清单之外，再给 AI 一张验收清单。 像那些每次都要重复做的检查，能让 AI 先跑一遍，就没必要再从头手动验一遍了。 得益于这套方法，最近我用 AI 轻轻松松搞了不少完整的作品，并且已经推广给不少人用了~ 比如下面这个游戏记录工具： ![](https://pic.yupi.icu/1/image-20260812144301650.png) 如果你也有一套写完代码后每次都会重复的检查流程，可以试着整理成 Skill。懒得从零写的话，可以用官方的 `skill-creator` 插件，它会像面试一样问你平时的工作流程，然后帮你自动生成。 话说回来，AI 能自己检查代码了，那还要程序员干嘛？ 答案很简单：**背锅**（bushi） AI 验收通过不代表万事 OK，它只能覆盖那些能明确判断对错的部分。真要上线出了问题，需求是谁定的、验收标准是谁写的、最终拍板上线的是谁，这些责任 AI 可背不了。 AI 是很好的执行者和检查员，但它不是决策者，更不是责任人。 所以别觉得什么「一人公司」就很轻松。你只是没看到人类背后被 AI 反复折磨、对着屏幕狂骂的样子罢了。 一个能做判断、敢扛责任的人，加上一个不知疲倦、执行力拉满的 AI，这才是当前最靠谱的组合。